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Abstract 


Multiprotocol Label Switching (MPLS) is a method for forwarding 
packets that uses short, fixed-length values carried by packets, 
called labels, to determine packet nexthops. A fundamental concept 
in MPLS is that two Label Switching Routers (LSRs) must agree on the 
meaning of the labels used to forward traffic between and through 
them. This common understanding is achieved by using a set of 
procedures, called a label distribution protocol, by which one LSR 
informs another of label bindings it has made. This document 
describes the applicability of a set of such procedures called LDP 
(for Label Distribution Protocol) by which LSRs distribute labels to 
support MPLS forwarding along normally routed paths. 


1. LDP Applicability 


A label distribution protocol is a set of procedures by which one 
Label Switching Router (LSR) informs another of the meaning of labels 
used to forward traffic between and through them. 


The MPLS architecture allows for the possibility of more than a 
single method for distributing labels, and a number of different 
label distribution protocols are being standardized. Existing 
protocols have been extended so that label distribution can be 
piggybacked on them, and new protocols have been defined for the 
explicit purpose of distributing labels. 
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This document describes the applicability of the Label Distribution 
Protocol (LDP), a new protocol for label distribution designed to 
support label distribution for MPLS forwarding along normally routed 
paths as determined by destination-based routing protocols. This is 
sometimes called MPLS hop-by-hop forwarding. 


LDP, together with an IP routing plane and software to program ATM 
switch or Frame Relay switch cross-connect tables, can implement IP 
in a network of ATM and/or Frame Relay switches without requiring an 
overlay or the use of ATM-specific or Frame Relay-specific addressing 
or routing. 


LDP is also useful in situations that require efficient hop-by-hop 
routed tunnels, such as MPLS-based VPN architectures [RFC2574] and 
tunneling between BGP border routers. 


In addition, LDP includes a mechanism that makes it possible to 
extend it to support MPLS features that go beyond best effort hop- 
by-hop forwarding. 


As a stand-alone protocol for distributing labels LDP does not rely 
on the presence of specific routing protocols at every hop along an 
LSP path in order to establish an LSP. Hence LDP is useful in 
situations in which an LSP must traverse nodes which may not all 
support a common piggybacked approach to distributing labels. 


Traffic Engineering [TE] is expected to be an important MPLS 
application. MPLS support for Traffic Engineering uses explicitly 
routed LSPs, which need not follow normally-routed (hop-by-hop) 
paths. 


Explicitly routed LSPs may be setup by CR-LDP [CRLDP-AS], a set of 
extensions to LDP, or by RSVP-TE [RSVP-TE-AS], a set of extensions to 
RSVP. There is currently no consensus on which of these protocols is 
technically superior. Therefore, network administrators should make 
a choice between the two based upon their needs and particular 
situation. 


2. Requirement Level 
The "requirement level" [RFC2026] for LDP is: 
Implementation of LDP is recommended for devices that perform MPLS 


forwarding along normally routed paths as determined by 
destination-based routing protocols. 
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3. Feature Overview 


LDP associates a Forwarding Equivalence Class (FEC) [RFC3031] with 
each label it distributes. Two LSRs which use LDP to exchange FEC- 
label binding information are known as "LDP Peers", and we speak of 
there being an "LDP Session" between them. 


LDP uses TCP for session communication. Use of TCP ensures that 
session messages are reliably delivered, and that distributed labels 
and state information associated with LSPs need not be refreshed 
periodically. 


LDP includes a mechanism by which an LSR can discover potential LDP 
peers. The discovery mechanism makes it unnecessary for operators to 
explicitly configure each LSR with its LDP peers. 


When an LSR discovers another LSR it follows the LDP session setup 
procedure to establish an LDP session. By means of this procedure 
the LSRs establish a session TCP connection and use it to negotiate 
parameters for the session, such as the label distribution method to 


be used (see below). After the LSRs agree on the parameters, the 
session is operational and the LSRs use the TCP connection for label 
distribution. 


LDP supports two different methods for label distribution. An LSR 
using Downstream Unsolicited distribution advertises FEC-label 
bindings to its peers when it is ready to forward packets in the FEC 
by means of MPLS. An LSR using Downstream on Demand distribution 
provides FEC-label bindings to a peer in response to specific 
requests from the peer for a label for the FEC. 


LDP allows LSRs flexibility in strategies for retaining learned 
labels. An LSR using liberal label retention stores all labels 
learned from peers regardless of whether it currently needs them for 
forwarding, whereas one using conservative label retention stores 
only labels for which it has immediate use and releases unneeded 
labels to the peer that advertised them. 


In addition, LDP allows flexibility in strategies for when to 
advertise FEC-label bindings. An LSR using independent control mode 
advertises FEC-label bindings to peers whenever it sees fit, whereas 
one using ordered control advertises bindings only when it has 
previously received a label for the FEC from the FEC nexthop or it is 
an MPLS egress for the FEC. 


Downstream on Demand distribution with conservative label retention 


and ordered control is appropriate in situations where labels are a 
relatively scarce resource that must be conserved, and Downstream 
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Unsolicited distribution with liberal label retention and independent 
control is appropriate where labels are plentiful and need not be 
carefully conserved. However, the protocol permits other 
combinations of distribution method, label retention mode and control 
mode, including hybrid variants of them. 


LDP defines a mechanism for loop detection to protect against 
forwarding loops in LSPs that traverse non-TTL MPLS clouds; see 
[RFC3031] for discussion of situations which may benefit from this 
mechanism. The loop detection mechanism is optional in the sense 
that it may be disabled by LSR configuration. However, an LDP- 
compliant LSR must implement it. 


LDP includes an extension mechanism which supports the development of 
vendor-private and experimental features. This mechanism defines 
procedures for introducing new types of messages and TLVs, methods an 
LSR can use for detecting such messages and TLVs, and procedures an 
LSR must follow when it receives a message or TLV it does not 
implement. While it is not possible to make every future enhancement 
backwards compatible, these procedures facilitate the introduction of 
new capabilities in MPLS networks that include older implementations 
that do not recognize them. 


4. Scalability Considerations 


The following factors may influence the scalability of LDP 
implementations: 


- LDP label distribution is incremental, requiring no periodic 
refresh of FEC-label bindings. 


- In situations were label resources may be scarce (ATM and Frame 
Relay links) the use of the Downstream on Demand distribution 
method with conservative label retention ensures that only 
those labels required to support normally-routed paths are 
allocated and distributed. 


- In situations where label resources are not scarce, the use of 
the Downstream Unsolicited method with liberal label retention 
ensures that changes in FEC nexthop from one LDP peer to 
another require no distribution action to update previously 
distributed labels. 


- Limitations on the number of TCP connections an LSR supports 
limit the number of LDP peers the LSR can support. 
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- Use of the optional path vector based loop detection mechanism 
imposes additional memory and processing requirements on an 
LSR, as well as additional LDP traffic. Both impact 
scalability. 


5. Security Considerations 


LDP defines the optional use of the TCP MD5 Signature Option to 
protect against the introduction of spoofed TCP segments into LDP 
session connection streams. LDP use of the TCP MD5 Signature Option 
is similar to BGP [RFC1771] use of the option specified in [RFC2385]. 
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8. Full Copyright Statement 
Copyright (C) The Internet Society (2001). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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